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ABSTRACT 

SHAMAN  (Spreadsheet-based  Hierarchical  Architecture 
for  MANagement)  is  a  novel  management  framework  de¬ 
veloped  at  the  University  of  Delaware;  it  extends  the  tra¬ 
ditional  flat  SNMP  management  model  to  a  hierarchi¬ 
cal  architecture.  Effective  management  of  battlefield  net¬ 
works  requires  such  a  hierarchical  management  architec¬ 
ture  wherein  managers  can  dynamically  delegate  man¬ 
agement  tasks  to  intermediate  managers.  The  SHAMAN 
framework  includes  a  spreadsheet-based  intermediate 
manager  with  a  scripting  language  and  MIB.  a  polling 
subsystem,  and  an  event  model;  a  prototype  implementa¬ 
tion  of  the  system  is  available.  Our  research  has  explored 
several  applications  of  the  SHAMAN  system  to  tactical 
battlefield  networks  for  the  US  Army.  These  applications 
described  in  this  paper  include  a  Location  Management 
application,  an  application  to  reconfigure  dynamically 
changing  topology  of  Tactical  Internets,  and  another  ap¬ 
plication  to  interface  with  OPNET  simulations  of  battle¬ 
field  networks. 

Keywords:  Network  Management,  Hierarchical  Man¬ 
agement,  SNMP,  Tactical  Internet,  Battlefield  Networks, 
Location  Management. 

INTRODUCTION 

One  of  the  significant  achievements  of  the  ATIRP  Con¬ 
sortium  in  Technical  Factor  2  (Tactical/Strategic  Interop¬ 
erability)  has  been  the  design  and  development  of  an  in- 
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tegrated  framework  for  hierarchical  management  called 
SHAMAN  (Spreadsheet-based  Hierarchical  Architecture 
for  MANagement).  This  management  system  developed 
at  the  Network  Management  Laboratory  of  the  University 
of  Delaware  incorporates  management  by  delegation  con¬ 
cepts  into  the  Internet  management  framework  to  facili¬ 
tate  the  management  of  distributed  systems  [1],  [2],  [3], 
[4].  This  architecture  allows  a  manager  to  delegate  rou¬ 
tine  management  tasks  to  an  intermediate  manager  and 
facilitates  user  configurability  of  management  informa¬ 
tion  and  control  in  a  value-added  manner. 

A  hierarchical  management  strategy  is  an  effective  means 
of  managing  the  large  and  complex  internetworks  that  arc 
in  use  today  [5],  The  need  for  hierarchical  management 
is  particularly  acute  in  tactical  battlefield  networks  which 
are  expected  to  have  tens  of  thousands  of  nodes.  Unfor¬ 
tunately,  the  most  popular  management  framework  in  use 
today,  the  SNMP  framework  [6],  [7],  [8],  only  supports 
the  flat  management  model.  The  framework  provides 
no  means  for  managers  to  delegate  tasks  to  intermediate 
managers  or  for  peer-to-peer  communication  between  in¬ 
termediate  managers  during  the  execution  of  these  tasks. 
SHAMAN  provides  this  much-needed  capability  to  the 
Internet  management  framework. 

This  paper  provides  a  brief  introduction  to  the  SHAMAN 
architecture  and  also  describes  how  it  can  be  used  for 
the  management  of  tactical  battlefield  networks.  We  start 
in  Section  2  with  a  brief  overview  of  SHAMAN.  Sec¬ 
tion  3  describes  a  Location  Management  Application  and 
its  interfacing  to  an  OPNET  simulation,  while  Section 
4  presents  a  Topology  Reconfiguration  Application.  Fi¬ 
nally,  Section  5  presents  the  conclusions. 


Fig.  1 .  Prototype  Implementation  of  SHAMAN 


I.  Overview  of  SHAMAN 

SHAMAN  allows  a  manager  to  delegate  tasks  to  an  inter¬ 
mediate  manager  (IM)  by  downloading  scripts  express¬ 
ing  these  tasks  into  a  spreadsheet-like  structure  of  the 
IM  called  the  Spreadsheet  MIR  [9],  [10].  This  MIB  is 
divided  into  a  two-dimensional  structure  of  cells  called 
a  spreadsheet,  with  each  cell  having  a  control  part  that 
stores  the  script  and  a  data  part  that  contains  the  result  of 
executing  the  script.  One  IM  can  support  multiple  spread¬ 
sheets. 

The  spreadsheet  MIB  implements  the  spreadsheets  using 
SNMP  tables.  All  operations  on  the  spreadsheet  includ¬ 
ing  a  manager’s  downloading  of  scripts  into  the  control 
parts  and  accessing  the  results  in  the  data  part  are  carried 
out  via  the  Get  and  Set  operations  of  the  SNMP  protocol. 
User  operations  on  cells  map  to  operations  on  tables  that 
arc  part  of  this  MIB.  When  the  IM  receives  an  SNMP  re¬ 
quest  from  the  manager  that  translates  to  an  operation  on 
a  cell,  the  IM  performs  the  necessary  operations  on  the 
spreadsheet  MIB  to  implement  the  cell  abstraction.  Once 
the  request  has  been  carried  out,  the  IM  returns  a  response 
to  the  manager  that  requested  the  cell  operation. 

The  scripts  in  SHAMAN  are  written  in  a  special  language 
called  the  Spreadsheet  Scripting  Language  (SSL).  This 
interpreted  language  contains  features  that  facilitate  the 
development  of  procedural  scripts  as  well  as  event  speci¬ 
fications.  The  language  includes 

•  procedural  language  related  features  including  opera¬ 
tors,  variable  support,  and  control  flow  constructs 

•  network  management  specific  features  including 
polling  specification  and  management  variable  access 

•  paradigm  specific  features  including  cell  access,  re¬ 


trieval,  modification,  and  multiple  value  access 
•  event  model  related  features  including  event  and  event 
dependency  specification 

A  prototype  implementation  of  SHAMAN  has  been  de¬ 
veloped  at  the  University  of  Delaware  and  is  available  on 
the  WWW  at  the  URL 

http  ://www.cis.udel.edu/~shaman 


Figure  1  depicts  the  various  modules  that  constitute  the 
Intermediate  Manager  (IM)  in  the  prototype  implementa¬ 
tion  of  SHAMAN.  Figure  I  shows  the  software  architec¬ 
ture  of  the  IM  and  the  interdependencies  of  the  various 
modules  that  constitute  the  IM.  Among  these  modules, 
the  MIB  Module,  the  Interpreter  Module,  and  the  Cell 
Module  together  implement  three  of  the  logical  compo¬ 
nents  of  the  IM.  The  Polling  Subsystem  implements  the 
polling  of  the  agents.  The  other  modules  perform  support 
functions  like  timer  services  and  providing  a  communi¬ 
cation  interface  for  polling  the  agents. 

II.  Location  Management  in  Battlefield  Networks 

Consider  a  scenario  of  location  management  for  mobile 
nodes  in  a  battlefield  network,,  in  which  a  group  of  nodes 
individually  move  on  a  battlefield  according  to  the  needs 
of  the  situation.  Each  node  has  an  SNMP-manageable 
MIB  with  variables  for  the  x  and  y  coordinates  of  the  cur¬ 
rent  node  position,  and  other  variables  corresponding  to 
various  quantities  of  interest,  such  as  amount  of  fuel  or 
ammunition  remaining  in  the  node.  Each  node  requires  to 
be  periodically  monitored  by  a  manager  who  keeps  track 


Fig.  2.  Hierarchical  Location  Management  for  Mobile  Nodes 
in  a  Battlefield  Network 


of  the  current  location  of  the  node  and  the  amounts  of  fuel 
and  ammunition  left,  and  which  may  take  appropriate  ac¬ 
tion  if  these  amounts  fall  below  specified  limits. 

The  total  number  of  such  nodes  to  be  managed  may  be 
too  large  for  a  single  manager  to  handle.  Moreover,  there 
may  be  distance  constraints  so  that  we  may  wish  to  have 
a  node  be  managed  by  a  manager  that  is  located  close 
by.  Figure  3  depicts  a  hierarchical  management  solu¬ 
tion  using  the  SHAMAN  approach  that  is  appropriate  for 
this  situation.  We  designate  two  Intermediate  Managers, 
named  IM1  and  IM2,  with  management  authority  over 
nodes  that  arc  within  their  spheres  of  communication  as 
shown  by  the  circles  in  the  figure.  Each  IM  periodically 
polls  each  node  within  its  management  domain  to  obtain 
its  current  variable  values.  If  any  action  is  required  for 
the  fuel  or  ammunition,  then  the  top-level  manager  is  in¬ 
formed. 

As  the  nodes  in  this  system  move  around,  they  may  mi¬ 
grate  from  the  management  domain  of  one  IM  to  the  do¬ 
main  of  the  other.  This  may  necessitate  a  “handoff”  of 
the  management  authority  over  this  node  to  the  second 
manager.  The  need  for  a  handoff  may  be  detected  by  the 
IM  responsible  for  each  node.  Each  time  a  node’s  loca¬ 
tion  is  polled,  it  can  be  determined  if  the  node  has  entered 
an  intermediate  zone  (shown  in  the  figure  as  the  intersec¬ 
tion  of  the  two  management  domains).  If  it  has,  and  if  it 
is  rapidly  moving  towards  the  second  zone,  the  top-level 
manager  is  informed  who  then  initiates  the  handoff  of  the 
node  to  the  second  IM. 


Even  though  the  example  presented  here  is  somewhat 
simplistic  and  a  real-life  situation  has  to  consider  other 
factors  such  as  failures  of  intermediate  managers,  it 
serves  to  illustrate  the  power  and  utility  of  hierarchical 
management.  This  example  has  been  programmed  into 
SHAMAN  in  the  form  of  a  demo  which  is  available  at 
the  SHAMAN  web  page.  In  this  example,  for  which 
scripts  have  been  written  in  the  Spreadsheet  Scripting 
Language  (SSL),  domains  arc  defined  for  two  Interme¬ 
diate  Managers  (IMs)  separated  by  vertical  lines  with  a 
common  overlapping  portion.  Each  IM  periodically  polls 
the  nodes  which  arc  in  its  own  domain.  The  top-level 
manager  can  get  an  IM  to  either  start  or  stop  the  polling 
of  a  given  node  by  activating  or  deactivating  the  appro¬ 
priate  scripts  in  that  IM.  When  a  node’s  poll  reveals  a 
new  position  for  that  node,  this  event  triggers  execution 
of  another  script  that  determines  if  the  node  is  still  within 
the  IM’s  domain,  and  also  computes  its  direction  of  travel 
and  its  velocity.  If  the  node  has  entered  the  overlapping 
zone  between  the  IM’s  and  is  traveling  quickly  towards 
the  other  IM’s  zone,  then  a  handoff  is  initiated  imme¬ 
diately;  if  it  is  traveling  slowly,  a  handoff  is  performed 
only  after  it  has  actually  entered  the  other  IM’s  zone.  To 
perform  the  handoff,  the  top-level  manager  is  informed 
who  then  activates  the  script  for  that  node  in  the  other 
IM  and  deactivates  it  in  the  first  IM.  It  is  also  possible 
in  the  SHAMAN  architecture  for  the  two  IM’s  to  directly 
communicate  with  each  other  and  perform  the  handoff 
without  involving  the  top-level  manager. 

Since  it  is  very  difficult  to  demonstrate  applications  such 
as  Location  Management  on  a  real  system  with  more  than 
a  few  nodes,  we  must  resort  to  simulation  in  order  to 
study  their  scalability  to  networks  with  large  numbers  of 
nodes.  Our  partner  in  the  ATIRP  Consortium,  Motorola, 
has  developed  simulation  models  of  realistic  battlefield 
situations  that  include  knowledge  and  modeling  of  ter¬ 
rain  information.  These  simulations  arc  implemented  us¬ 
ing  OPNET  [11]  and  demonstrate  node  mobility  in  dif¬ 
ferent  types  of  terrain  and  the  effect  on  communication 
patterns  [12],  We  have  developed  a  simulated  MIB  in¬ 
terface  that  allows  us  to  connect  the  OPNET  simulations 
with  the  SHAMAN  management  system  [13]. 

III.  Topology  Reconfiguration  with  SHAMAN 

A  tactical  battlefield  network  is  characterized  by  a  spo¬ 
radically  changing  topology,  due  to  the  sudden  appear¬ 
ance  and  disappearance  of  the  network  elements  (e.g., 
routers,  switches,  links,  etc.).  Thus,  an  important  compo- 


nent  of  the  an  adaptive  configuration  management  system 
is  to  generate/re-generate  an  appropriate  network  con¬ 
nectivity  after  a  change  has  occurred  in  the  underlying 
network  (i.e.,  adapt  and  respond  to  network  triggers). 
Broadly  speaking,  while  many  schemes  exist  to  gener¬ 
ate  network  topology  the  complexity  of  the  scheme  in¬ 
creases  in  direct  relation  to  the  degree  of  optimality  re¬ 
quired.  Strictly  optimal  solutions  may  not  only  be  too 
complex,  but  also  may  be  intractable.  On  the  other  hand, 
completely  ad-hoc  solutions  may  not  yield  consistent  re¬ 
sults. 

Our  partners  in  the  ATIRP  Consortium,  Telcordia,  have 
designed  a  heuristic  algorithm  to  compute  the  new  topol¬ 
ogy  in  such  a  situation  [14],  [15].  This  algorithm  applies 
a  number  of  heuristics  to  generate  connectivity  within  a 
Tactical  Internet  (TI)  which  are  based  on  using  the  well- 
known  Dijkstra’s  shortest-path  algorithm  to  compute  the 
shortest  path  tree  from  a  given  node  to  all  other  nodes 
within  the  network.  This  shortest  path  algorithm  is  mod¬ 
ified  to  accommodate  the  constraints  that  arc  imposed  on 
the  configuration  by  the  application.  Three  constraints 
that  arc  used  are: 

•  Every  node  in  the  network  must  be  able  to  communi¬ 
cate  with  every  other  node  via  at  least  one  path  that  is  less 
than  H  hops  long. 

•  Every  communicating  node  pair  has  more  than  one  pos¬ 
sible  routes  through  the  underlying  network  (to  provide 
redundancy  in  case  there  arc  failures). 

•  There  is  a  a  maximum  limit  on  the  number  of  other 
nodes  with  which  any  given  node  has  direct  connectivity. 

To  implement  this  algorithm  in  SHAMAN,  we  have 
planned  to  use  a  structure  of  cells  in  the  spreadsheet 
which  will  make  it  easy  to  modularize  the  different  log¬ 
ical  components  of  the  algorithm.  The  first  column  of 
cells  arc  used  for  external  interaction  from  the  SHAMAN 
entity,  i.e.,  for  communication  with  the  top-level  man¬ 
ager.  This  column  includes  a  cell  used  as  the  bigger  for 
topology  generation.  The  manager  will  do  an  SNMPGet 
operation  on  this  cell  to  command  the  SHAMAN  IM  to 
begin  topology  reconfiguration  when  it  is  necessary  to  do 
so.  Another  cell  is  used  to  store  the  generated  topology; 
this  topology  is  then  set  into  an  agent  MIB  that  is  used  to 
drive  the  input  to  the  directory  service  system  from  where 
it  is  accessible  to  the  manager. 

A  second  column  of  cells  stores  global  parameters  and 
data.  These  include  the  number  of  nodes  in  the  network. 


the  node  addresses,  the  maximum  limit  on  nodal  connec¬ 
tivity,  and  the  limit  on  the  maximum  length  of  the  shortest 
path  between  two  nodes.  The  third  column  contains  local 
structures  to  be  used  by  the  various  components  of  the  al¬ 
gorithm.  These  are  the  node  positions  (which  arc  polled 
from  the  agents  in  the  nodes,  or  may  be  obtained  from  the 
DSS),  the  path  cost  matrix,  the  direct  link  costs,  and  the 
predecessor  of  each  node  in  the  shortest  path  tree. 

The  remaining  columns  and  cells  in  SHAMAN’s  spread¬ 
sheet  arc  used  for  the  code  corresponding  to  the  algo¬ 
rithm's  components.  The  first  of  these  is  the  Chain  gener¬ 
ation  function,  which  initially  generates  chains  between 
the  nodes  that  arc  as  long  as  possible  without  violating 
the  maximum  length  constraints.  The  second  is  Dijkstra’s 
algorithm  which  finds  the  shortest  paths  from  each  node 
to  every  other  node.  The  third  component  is  a  function 
to  create  shorter  paths  whenever  the  algorithm  has  paths 
that  arc  unacceptably  long.  This  is  done  by  adding  di¬ 
rect  links  between  the  nodes  so  that  path  lengths  may  be 
reduced.  The  final  component  is  a  function  to  perform 
checks  on  the  nodal  degree  consbaint. 

Implementation  of  this  algorithm  in  SHAMAN  is  cur¬ 
rently  underway  and  we  hope  to  be  able  to  give  a  demon- 
sration  of  the  SHAMAN  paid  of  the  system  at  the  upcom¬ 
ing  Annual  Conference.  The  integration  of  this  with  the 
rest  of  the  system  being  developed  by  our  other  task  part¬ 
ners  will  be  done  shortly  afterwards,  and  the  complete 
joint  demo  should  be  available  for  demonstration  before 
the  end  of  the  project. 

The  remaining  columns  and  cells  in  SHAMAN’s  spread¬ 
sheet  arc  used  for  the  code  corresponding  to  the  algo¬ 
rithm's  components.  The  first  of  these  is  the  Chain  gener¬ 
ation  function,  which  initially  generates  chains  between 
the  nodes  that  arc  as  long  as  possible  without  violating 
the  maximum  length  constraints.  The  second  is  Dijkstra’s 
algorithm  which  finds  the  shortest  paths  from  each  node 
to  every  other  node.  The  third  component  is  a  function 
to  create  shorter  paths  whenever  the  algorithm  has  paths 
that  arc  unacceptably  long.  This  is  done  by  adding  di¬ 
rect  links  between  the  nodes  so  that  path  lengths  may  be 
reduced.  The  final  component  is  a  function  to  perform 
checks  on  the  nodal  degree  consbaint. 

Implementation  of  this  algorithm  in  SHAMAN  is  cur¬ 
rently  underway  and  we  hope  to  be  able  to  give  a  demon- 
sration  of  the  SHAMAN  paid  of  the  system  at  the  upcom¬ 
ing  Annual  Conference.  The  integration  of  this  with  the 


rest  of  the  system  being  developed  by  our  other  task  part¬ 
ners  will  be  done  shortly  afterwards,  and  the  complete 
joint  demo  should  be  available  for  demonstration  before 
the  end  of  the  project. 

IV.  Conclusions 

In  conclusion,  one  of  the  significant  achievements  of 
the  ATIRP  Consortium  in  the  area  of  network  manage¬ 
ment  has  been  the  development  of  the  SHAMAN  system. 
SHAMAN  is  an  architecture  and  framework  for  hierar¬ 
chical  management  of  networks  that  can  be  applied  to  im¬ 
plement  various  management  applications  in  the  Army’s 
tactical  battlefield  networks.  We  have  described  its  util¬ 
ity  for  location  management  of  mobile  nodes  in  a  bat¬ 
tlefield  environment  and  for  a  configuration  management 
application  that  can  be  used  to  reconfigure  network  topol¬ 
ogy  when  node  positions  have  changed.  A  prototype  im¬ 
plementation  of  SHAMAN  is  available  and  will  soon  be 
ported  to  the  ARL  Testbed  so  it  can  be  used  for  other 
management  tasks  and  applications  within  the  Testbed. 

The  views  and  conclusions  contained  in  this  document  are 
those  of  the  authors  and  should  not  be  interpreted  as  repre¬ 
senting  the  official  policies,  either  expressed  or  implied,  of  the 
Army  Research  Laboratory  or  the  U.S.  Government. 
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